iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 26
0
DevOps

.NET Core 專案持續整合與部署系列 第 26

Integrate:NuGet v.s. VISX

  • 分享至 

  • xImage
  •  
# Outline
一、前言
二、兩者差異
  2-1. 範疇(Scope)
  2-2. 建置錯誤(Build Error)
  2-3. 規則層級(Rule severity)
三、結語

# TL;DR
若是某功能是想要團隊共同遵守或是能在 CI 上執行,就以 NuGet packages 的形式安裝吧!

這篇算是補述前面沒提到的簡單概念。
——Day 26

一、前言

在以往,我們都是相依 Visual Studio 這套 IDE 進行程式編寫,仰賴它幫我執行各項操作,像是建置、程式碼檢查等,為了更多功能,我們都會透過安裝 Visual Studio 延伸模組 (VSIX) 取得。但是既然我們要開始學習使用 CLI 操作,就會失去 IDE 的輔助,任何原本在 IDE 進行的事物都要在 CLI 找尋替代方案,這也就是為什麼我們要改用 NuGet 去安裝相依套件 (NuGet package),因為 NuGet package 是與專案本身繫結的,無關 IDE,自然就可以透過 CLI 操作,也可以跟著程式碼版本控制,更重要的是能在未來透過 CI 工具去執行。那使用 VSIX 和 NuGet package 在使用上有何差異呢?就是本文想要簡述的。

二、兩者差異

2-1. 範疇(Scope)

VSIX 在 Scope 上,通常是跟隨 Visual Studio 的,所以範圍通常會是使用該 Visual Studio 的所以有 Solution 和 Project,基本上可視為 Solution 層級,對該 Solution 底下的 Projects 當然就一併適用。

而 NuGet 是與 Project 綁定的,任何 NuGet 的安裝都必須指定特定 Project,所以效果的範疇自然也只陷於該 Project。若是要將範疇套用在所有 Projects,那麼就必須一個個安裝,儘管麻煩但是卻可以換來各個 Project 客製化的彈性。用一個例子來說,若是針對特定幾個專案進行程式碼風格檢查,那就是針對那幾個專案安裝 StyleCop.Analyzers 套件即可。

透過安裝 NuGet 套件的好處,就如同前言所述,相關資訊也會隨著程式碼進入版本控制,所以所有開發團隊的成員當然也會一併同步。如同上面舉的程式碼風格的例子,我們就不用一個個請圖隊成員安裝 VSIX,他們只要 check-out 最新的版本,就會一併套用程式碼風格的檢查了。

2-2. 建置錯誤(Build Error)

如果我們是仰賴 VSIX 去檢查錯誤,在程式碼有不符合規則時於 IDE 顯示。那麼今天為了 CI 改用 CLI 的情境下,這些錯誤就都不會顯示了。但若是改用 NuGet package,在使用 IDE 時同樣會檢查出錯誤。

所以若是希望某項檢查能在 CLI 介面執行時也被執行,以將錯誤暴露出來,就會建議將相關功能改用 NuGet Packages 的形式進行安裝。

規則層級(Rule severity)

如果 Code Analyzers 是透過 VSIX 安裝的話,就無法針對每個項目去設定其規則層級是 error、warning、info、hide。若想進行這方面的客製化的話,請透過 NuGet 安裝 Code Analyzers。

結語

總結來說,NuGet packages 的特色在於可以針對特定專案、能透過 CLI 介面操作時被執行、能夠隨程式碼進入版本控制。所以若是一些功能希望能團隊共享或是共同遵守,就像是本系列文追求的 Ci,就會建議改用 NuGet packages 安裝;若該功能只是個人輔助使用,就放心地使用 VSIX 吧!


上一篇
Virtualize:透過 GCP Container Registry 部署
下一篇
導讀:.NET Core 與 .NET 的歷史
系列文
.NET Core 專案持續整合與部署31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言